ETSITS101 356v7.o.o 



(1999-07) 



Technical Specification 



Digital cellular telecommunications system (Phase 2+); 

General Packet Radio Service (GPRS); 

Mobile Station (MS) supporting GPRS 

(GSM 07.60 version 7.0.0 Release 1998) 



GS 



GLOBAL SYSTEM FOR 
MOBILE COMMUNICATIONS 




(GSM 07.60 version 7.0.0 Release 1 998) 2 ETSI TS 1 01 356 V7.0.0 (1 999-07) 



Reference 



RTS/SMG-030760Q7 (ck003i03.PDF) 

Keywords 

Digital cellular telecommunications system, 

Global System for Mobile communications 

(GSM), GPRS 



ETSI 

Postal address 



F-06921 Sophia Antipolis Cedex - FRANCE 

Office address 

650 Route des Lucioles - Sophia Antipolis 

Valbonne - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Internet 



secretariat@etsi.fr 

Individual copies of this ETSI deliverable 

can be downloaded from 

http://www.etsi.org 

If you find errors in the present document, send your 

comment to: editor@etsi.fr 



Copyright Notification 



No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 



© European Telecommunications Standards Institute 1999. 
All rights reserved. 



ETSI 



(GSM 07.60 version 7.0.0 Release 1 998) 3 ETSI TS 1 01 356 V7.0.0 (1 999-07) 



Contents 



Intellectual Property Rights 6 

Foreword 6 

Introduction 6 

1 Scope 7 

2 References 7 

3 Definitions abbreviations and symbols 10 

3.1 Definitions 10 

3.2 Abbreviations 10 

3.3 Symbols 11 

4 Access reference configuration 11 

5 Functions to support data services 11 

6 Interface to GPRS Bearer Services 12 

7 Functions common to all configurations of the GPRS MS 12 

7.1 Mobile Classes 12 

7.2 Physical Interface 12 

7.3 Terminal context procedures 12 

7.3.1 GPRS Attach 12 

7.3.2 GPRS Detach 12 

7.3.3 Mobile Originated PDP Context Activation 13 

7.3.4 Network Requested PDP Context Activation 13 

7.3.5 PDP Context Deactivation 13 

7.3.6 PDP context related parameters 13 

8 X.25 Based Services 13 

8.1 X.25 Character mode (triple X PAD) service 14 

8.1.1 PAD Parameters 15 

8.1.2 Example mapping of functions between the R reference point and the GPRS bearer 16 

8.2 X.25 Packet mode service 16 

8.2.1 Layer 1 and Layer 2 options 17 

8.2.1.1 Synchronous serial interface 17 

8.2.1.2 Asynchronous serial interface 17 

8.2.1.3 Synchronous and asynchronous (dual mode) interface 17 

8.2.2 Example mappings of functions between the R reference point and the GPRS bearer 18 

8.2.2.1 Standardized X.25 TE 18 

8.2.2.1.1 Layer 1 control 18 

8.2.2.1.2 Layer 2 control 18 

8.2.2.1.3 Layer 3 control 19 

8.2.2.2 X.25 TE with support for AT commands 19 

9 IP Based Services 20 

9. 1 Example mapping of functions between the R reference point and the GPRS bearer for IP over PPP 20 

10 PPP Based Services 23 

10.1 Example mapping of functions between the R reference point and the GPRS bearer 23 

11 Internet Hosted Octet Stream Service (IHOSS) 25 

11.1 Introduction 25 

11.2 Example of protocol stacks at the MT 25 

11.3 IHOSS connection control and OSP PDP context management 26 

11.3.1 Connection establishment and PDP context activation 26 

11.3.2 Connection release and PDP context deactivation 27 

11.4 OSPTHOSS subset of OSP 27 

11.4.1 Required features 27 



ETSI 



(GSM 07.60 version 7.0.0 Release 1 998) 4 ETSI TS 1 01 356 V7.0.0 (1 999-07) 

11.4.1.1 User data transport 27 

11.4.1.2 Flow control 27 

11.4.2 Optional features 27 

11.4.2.1 Break handling 27 

11.4.2.2 Packet Assembler/Disassembler 27 

11.4.2.3 GGSN maximum buffer size negotiation 27 

11.4.3 Not-required features 27 

11.5 Protocol option parameters 28 

11.5.1 Hostname 28 

11.5.2 Port Number 28 

11.5.3 Protocol Type - TCP or UDP 28 

11.5.4 GGSN PAD parameters (maximum buffer sizes only) 28 

12 AT commands 28 

12.1 General on AT commands 29 

12.1.1 Interaction of AT commands, GPRS management and PDPs 29 

12.1.1.1 AT commands and responses 29 

12.1.1.2 PDP and layer 2 protocol operation 29 

12.1.1.3 GPRS management 29 

12.1.1.3.1 GPRS attachment 30 

12.1.1.3.2 PDP context activation 30 

12.1.2 Use of default context parameter values 30 

12.1.2.1 PDP type 30 

12.1.2.2 PDP address (of the MS) 30 

12.1.2.3 Access Point Name 30 

12.1.2.4 QoS Requested 30 

12.1.2.5 PDP Configuration Options 31 

12.2 Example command sequences for dial-compatibility mode 31 

12.2.1 PPP in dial compatibility mode 31 

12.2.1.1 Mobile initiated IP context activation 31 

12.2.1.2 Network requested IP context activation 32 

12.2.2 MO X.25 virtual call using a triple-X PAD in dial compatibility mode 33 

Annex A (informative): Summary of AT commands for GPRS 34 

Annex B (informative): Octet Stream Protocol (OSP) PDP type 35 

B.l Scope 35 

B.2 Service primitives 36 

B.2.1 Service Primitives provided by the OSP layer 36 

B.2.1.1 OS-DATA.request 37 

B.2.1.2 OS -DATA, indication 37 

B.2.1. 3 OS-UNITDATA.request 37 

B.2.1.4 OS-UNITDATA.indication 37 

B.2.1.5 OS-FLOWCONTROL.request 37 

B.2.1.6 OS-FLOWCONTROL.indication 37 

B.2.1.7 OS-BREAK.request 37 

B.2.1. 8 OS-BREAK.indication 38 

B.2.1.9 OS-CONTROL.request 38 

B.2.1. 10 OS-CONTROL.indication 38 

B.2.1. 11 OS-FORWARD.request 38 

B.2. 2 Service Primitives Used by the OSP Layer 38 

B.2.2.1 SN-DATA.request 38 

B.2.2.2 SN-DATA.indication 38 

B.2.2.3 SN-UNITDATA.request 38 

B.2.2.4 SN-UNITDATA.indication 38 

B.2.2.5 GT-DATA.request 39 

B.2.2.6 GT-DATA.indication 39 

B.2.2.7 GT-UNITDATA.request 39 

B.2.2.8 GT-UNITDATA.indication 39 



ETSI 



(GSM 07.60 version 7.0.0 Release 1 998) 5 ETSI TS 1 01 356 V7.0.0 (1 999-07) 

B.3 OSP Functional model 39 

B.4 OSP N-PDU (packet) format 40 

B.4.1 OSP header 40 

B.4.1.1 Bit 1 - Extension (E) 40 

B.4.1.2 Bit 2 - Ready to Receive (RTR) - flow control 40 

B.4.1.3 Bit 3 - Break Request (BR) 41 

B.4.1.4 Bit 4 - Break Acknowledge (BA) 41 

B.4.1.5 bit 8 - payload type (PT) 41 

B.4.2 OSP payload 41 

B.4.2.1 User data 41 

B.4.2.2 Control block 41 

B.5 Packet Assembly/Disassembly (PAD) function 41 

B.5.1 Packet Assembler 41 

B.5. 1.1 Buffer full 42 

B.5. 1.2 Inactivity timer expiry 42 

B.5. 1.3 Maximum Buffer Delay timer expiry (optional) 42 

B.5. 1.4 Special character(s) 42 

B.5. 1.5 Change in flow control state 43 

B.5. 1.6 Immediate forwarding request 43 

B.5. 2 Packet Disassembler 43 

B.6 Flow control 43 

B.7 Break handling 44 

B.8 Control block transport 44 

B.9 Quality of Service 44 

B.10 OSP version 44 

B.ll Protocol Configuration Options 45 

B.ll.l OSP version 45 

B.11.2 GGSN PAD parameters 45 

Annex C (informative): Document change history 46 

History 47 



ETSI 



(GSM 07.60 version 7.0.0 Release 1 998) 6 ETSI TS 1 01 356 V7.0.0 (1 999-07) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by the Special Mobile Group (SMG). 

The present document provides the necessary information to develop a MS for support of GPRS within the digital 
cellular telecommunications system. 

The contents of the present document are subject to continuing work within SMG and may change following formal 
SMG approval. Should SMG modify the contents of the present document it will then be republished by ETSI with an 
identifying change of release date and an increase in version number as follows: 

Version 7.x.y 

where: 

7 indicates GSM Release 1998 of Phase 2+ 

x the second digit is incremented for changes of substance, i.e. technical enhancements, corrections, updates, 
etc. 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 



Introduction 



The present document contains the necessary information to develop a MS for support of GPRS. It is up to the 
manufacturer how to implement the various functions but this specification and existing GSM 07.01, 07.02, and 07.03 
shall be followed where applicable. 

It is the intention that the present document shall remain as the specification to develop a MS for support of GPRS and 
its text includes references to GSM standards. 
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Scope 



The GSM PLMN supports a wide range of voice and non-voice services in the same network. In order to enable 
non-voice traffic in the GSM PLMN there is a need to connect various kinds of terminal equipments to the Mobile 
Station (MS). The present document describes the functionality of a MS supporting GPRS, including the protocols and 
signalling needed to support the first phase of GPRS, as defined in GSM 02.60 and 03.60 (packet based services). 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or non- 
specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

• For this Release 1998 document, references to GSM documents are for Release 1998 versions (version 7.x.y). 

[I] GSM 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and 
acronyms".. 

[2] GSM 02.02: "Digital cellular telecommunication system (Phase 2+); Bearer Services (BS) 

supported by a GSM Public Land Mobile Network (PLMN)". 

[3] GSM 02.60: "Digital cellular telecommunication system (Phase 2+); General Packet Radio Service 

(GPRS); Service Description Stage 1". 

[4] GSM 03.02: "Digital cellular telecommunication system (Phase 2+); Network architecture". 

[5] GSM 03.03: "Digital cellular telecommunications system (Phase 2+); Numbering, addressing and 

identification". 

[6] GSM 03. 10: "Digital cellular telecommunication system (Phase 2+); GSM Public Land Mobile 

Network (PLMN) connection types". 

[7] GSM 03.22: "Digital cellular telecommunications system (Phase 2+); Functions related to Mobile 

Station (MS) in idle mode and group receive mode". 

[8] GSM 03.40: "Digital cellular telecommunications system (Phase 2+); Technical realization of the 

Short Message Service (SMS); Point-to-Point (PP)". 

[9] GSM 03.60: "Digital cellular telecommunication system (Phase 2+); General Packet Radio Service 

(GPRS) Service Description Stage 2". 

[10] GSM 04.02: "Digital cellular telecommunication system (Phase 2+); GSM Public Land Mobile 

Network (PLMN) access reference configuration". 

[II] GSM 04.07: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface 
signalling layer 3; General aspects". 

[12] GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface 

layer 3 specification". 

[13] GSM 04.60: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Mobile Station (MS) - Base Station System (BSS) interface; Radio Link Control / 
Medium Access Control (RLC/MAC) protocol". 



ETSI 



(GSM 07.60 version 7.0.0 Release 1 998) 8 ETSI TS 1 01 356 V7.0.0 (1 999-07) 

[14] GSM 04.64: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Logical Link Control (LLC)". 

[15] GSM 04.65: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Subnetwork Dependent Convergence Protocol (SNDCP)". 

[16] GSM 07.07: "Digital cellular telecommunication system (Phase 2+); AT command set for GSM 

Mobile Equipment (ME)". 

[17] GSM 09.61: "Digital cellular telecommunication system (Phase 2+); General Packet Radio Service 

(GPRS); Interworking between the Public Land Mobile Network (PLMN) supporting GPRS and 
Packet Data Networks (PDN)". 

[18] CCITT Recommendation E. 164: "Numbering plan for the ISDN era". 

[19] CCITT Recommendation V.42 bis: "Data communication over the telephone network - Data 

compression procedures for data circuit-terminating equipment (DCE) using error correction 
procedures". 

[20] CCITT Recommendation X.3: "Packet assembly disassembly facility (PAD) in a public data 

network". 

[21] CCITT Recommendation X.25: "Interface between data terminal equipment (DTE) and data 

circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to 
public data networks by dedicated circuit". 

[22] CCITT Recommendation X.28: "DTE / DCE interface for a start-stop mode data terminal 

equipment accessing the packet assembly / disassembly facility (PAD) in a public data network 
situated in the same country". 

[23] CCITT Recommendation X.29: "Procedures for the exchange of control information and user data 

between a packet assembly / disassembly (PAD) facility and a packet mode DTE or another PAD". 

[24] CCITT Recommendation X.75: "Packet-switched signalling system between public networks 

providing data transmission services". 

[25] CCITT Recommendation X.121: "International Numbering Plan for Public Data Networks". 

[26] IETF RFC 768 (1980): "User Datagram Protocol" (STD 6). 

[27] IETF RFC 791 (1981): "Internet Protocol" (STD 5). 

[28] IETF RFC 792 (1981): "Internet Control Message Protocol" (STD 5). 

[29] IETF RFC 793 (1981): "Transmission Control Protocol" (STD 7). 

[30] ITU-T Recommendation V.250 (ex V.25ter): "Serial asynchronous automatic dialling and control". 

[31] ITU-T Recommendation V.24: "List of definitions for interchange circuits between data terminal 

equipment (DTE) and data circuit- terminating equipment (DCE)". 

[32] ITU-T Recommendation V.28: "Electrical Chracteristics for unbalanced double-current 

interchange circuits" 

[33] ITU-T Recommendation V.80: "In-band DCE control and synchronous data modes for 

asynchronous DTE" 

[34] IETF RFC 1661 (1994): "The Point-to-Point Protocol (PPP)" (STD 51). 

[35] IETF RFC 1662 (1994): "PPP in HDLC-like framing" (STD 51). 

[36] IETF RFC 1700 (1994): "Assigned Numbers" (STD 2). 

[3]7 IETF RFC 1570 (1994):"PPP LCP Extensions". 

[38] IETF RFC 1989 (1996):"PPP Link Quality Monitoring". 



ETSI 



(GSM 07.60 version 7.0.0 Release 1 998) 9 ETSI TS 1 01 356 V7.0.0 (1 999-07) 

[39] IETF RFC 1332 (1992):"The PPP Internet Protocol Control Protocol (IPCP)". 

[40] IETF RFC 1877 (1995):"PPP IPCP Extensions for Name Server Addresses ". 

[41] IETF RFC 2153 (1997):"PPP Vendor Extensions". 

[42] IETF RFC 1334 (1992):"PPP Authentication Protocols". 

[43] IETF RFC 1994 (1996):"PPP Challenge Handshake Authentication Protocol". 



ETSI 



(GSM 07.60 version 7.0.0 Release 1998) 



10 



ETSI TS 101 356 V7.0.0 (1999-07) 



Definitions abbreviations and symbols 



3.1 



Definitions 



Refer to: GSM 02.60 [2]. 

In GSM 02.02 the bearer services are described. The general network configuration is described in GSM 03.02 and the 
GSM PLMN access reference configuration is defined in GSM 04.02. The various connection types used in the GSM 
PLMN are presented in GSM 03.10. Terminology used in the present document is presented in GSM 01.04. For support 
of data services between GSM PLMN and other networks see GSM 09-series of Specifications. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

APN Access Point Name 

GGSN Gateway GPRS Support Node 

GPRS General Packet Radio Service 

GSN GPRS Support Node 

GTP GPRS Tunnelling Protocol 

HDLC High Level Data Link Control 

ICMP Internet Control Message Protocol 

IHOSS Internet Hosted Octet Stream Service 

IETF Internet Engineering Task Force 

IP Internet Protocol 

IPv4 Internet Protocol version 4 

IPv6 Internet Protocol version 6 

LA Location Area 

LAPB Link Access Protocol Balanced 

LCP Link Control Protocol 

LLC Logical Link Control 

MAC Medium Access Control 

ME Mobile Equipment 

MS Mobile Station 

MT Mobile Termination 

NCP Network Control Protocol 

OSP Octet Stream Protocol 

OSPTHOSS Octet Stream Protocol for Internet Hosted Octet Stream Service 

PAD Packet Assembler/Disassembler 

PDN Packet Data Network 

PDP Packet Data Protocol , e.g., IP, X.25 or PPP 

PDU Protocol Data Unit 

PSPDN Packet Switched Public Data Network 

PTM Point To Multipoint 

PTP Point To Point 

PVC Permanent Virtual Circuit 

RA Routing Area 

SGSN Serving GPRS Support Node 

SNDCP SubNetwork Dependent Convergence Protocol 

TE Terminal Equipment 

TCP Transmission Control Protocol 

UDP User Datagram Protocol 
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3.3 Symbols 



For the purposes of the present document, the following Symbols apply: 



Gb 
Gi 
Gn 
Gp 

Gs 
R 

Um 



Interface between an SGSN and a BSC. 

Reference point between GPRS and an external packet data network. 

Interface between two GSNs within the same PLMN. 

Interface between two GSNs in different PLMNs. The Gp interface allows support of GPRS 

network services across areas served by the co-operating GPRS PLMNs. 

Interface between an SGSN and MSC. 

The reference point between a non-ISDN compatible TE and MT. Typically this reference point 

supports a standard serial interface. 

The interface between the MS and the GPRS fixed network part. The Um interface is the GPRS 

network interface for providing packet data services over the radio to the MS. The MT part of the 

MS is used to access the GPRS services through this interface. 



Access reference configuration 



Figure 1 shows the relationship between the MS, its terminal equipment and the GSM network in the overall GPRS 
environment. 



R 



reference point T . 



Gi 

reference point 



GSM GPRS 

network 1 





GSM GPRS 

network 2 



Figure 1 : GPRS Access Interfaces and Reference Points 



5 Functions to support data services 

The main functions of the MT to support data services are: 
- physical connection at the reference point R; 
flow control between TE and MT; 
mapping of user signalling to/from the GPRS bearer; 

support of data integrity between the terminal equipment and the GPRS bearer; 
functions to support character based data; 
functions to support packet based data; 
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Interface to GPRS Bearer Services 



The following figure 2: Transmission Plane shows the relationship of the GPRS Bearer terminating at the SNDCP layer 
to the rest of the GPRS environment. It is shown for reference purposes only and detailed information can be found in 
GSM 03.60. 
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NOTE: In the SGSN and GGSN UDP is mandatory. TCP is optional but recommended for X.25 services. 

Figure 2: GPRS Transmission Plane 



Functions common to all configurations of the GPRS 
MS 



7.1 



Mobile Classes 



Three GPRS MS classes are identified: Class A, B, and C. These classes are described in GSM 02.60. 



7.2 Physical Interface 



The physical interface between the TE and the MT may conform to CCITT/ITU-T V.24/V.28, or to IrDA IrPHY 
physical standard specification, or to PCMCIA PC -Card electrical specification. All signal levels and their operation 
shall be as specified in GSM 07.01, 07.02, and 07.03. This shall not preclude any new developments such as USB 
(Universal Serial Bus). 



7.3 Terminal context procedures 



This subclause describes the relationships for GPRS Attach and Detach, and PDP Context Activation and Deactivation. 
The procedures for these functions are described in GSM 03.60. 



7.3.1 



GPRS Attach 



The GPRS Attach shall be performed prior to activating a PDP context. The GPRS Attach may be performed 
automatically or manually depending on the manufacturer's implementation and configuration. 

7.3.2 GPRS Detach 

The GPRS Detach may be performed automatically or manually depending on the manufacturer' s implementation and 
configuration. The following cases are valid: 
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if the connection between the TE and MT is broken then the MT may perform the GPRS Detach procedure; 

if the network originates a GPRS Detach the MT may inform the TE; 

if the radio connection is broken then the MT may inform the TE; 

if the TE deactivates the last PDP context then the MT may perform the GPRS Detach procedure. 

7.3.3 Mobile Originated PDP Context Activation 

The PDP Context Activation may be performed automatically or manually depending on the manufacturer' s 
implementation and configuration. Depending on the manufacturer' s implementation and configuration, 0, 1 , or more 
PDP contexts can be active simultaneously. 

7.3.4 Network Requested PDP Context Activation. 

The network can request a GPRS attached MS to activate a specific PDP context. 

7.3.5 PDP Context Deactivation 

The PDP Deactivation may be performed automatically or manually depending on the manufacturer's implementation 
and configuration. The following cases are valid: 

if the connection between the MT and the TE is broken then the MT may perform the PDP Context Deactivation 
procedure. 

if the radio connection is broken then the MT may inform the TE. 

if the TE deactivates the last PDP context then the MT may perform the GPRS Detach procedure. 

7.3.6 PDP context related parameters 

It shall be possible to enquire and/or set the following parameters: 

Requested Quality of Service. 

(this includes the peak bit rate, the mean bit rate, the delay requirements, the service precedence, and the 

reliability level) 

Data Compression on or off. 

TCP/IP Header Compression on or off. 

PDP address 

- PDP type 

Access Point Name (APN) 

Protocol configuration options (if required by the PDP type) 



8 X.25 Based Services 



This clause describes the use of X.25 based services over the GPRS bearer. Two services are specified at the R 
reference point - 

1) Character mode (specified in ITU-T X.3, X.28, X.29) with the triple X PAD in the MT. 

2) Packet mode (specified in ITU-T X.25). 
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NOTE: In order to maintain consistency within GSM specifications, the term TE is used when referring to what 

CCITT/ITU-T X.25 calls a DTE. Exceptionally, in text quoted from an ITU-T Recommendation, the term 
DTE is retained. 

8.1 X.25 Character mode (triple X PAD) service 

This mode is an asynchronous character based service allowing the application to set up a single connection using the 
CCITT/ITU-T X.28 / X.29 procedures. This supports both mobile originate and mobile terminate calls. The MT 
terminates the X.25 packet layer and provides a triple X PAD function. 
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Figure 3: Character (Triple X PAD) mode 
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8.1.1 PAD Parameters 

The following table lists the minimum set of X.3 parameters that shall be implemented. A full range is specified in the 
CCITT/ITU-T X series documents and those parameters not implemented shall be fixed to their defined defaults. 

Table 1 : Table of Minimum X.3 Parameters 



Parameter 
Number 


Description 


Default 
Value 


Valid 
Values 


Value/Function 


1 


PAD Recall Character 


1 




1 

32-36 


(None) 

DLE 

Binary representation of decimal value 


2 


Echo 







1 


Off 
On 


3 


Data Forwarding 
Character 


2 




1 

2 

4 

8 

16 

32 

64 


(on 128th data byte) 

A-Z, a-z, 0-9 

CR 

ESC, BEL, ENQ, ACK 

DEL, CAN, DC2 

ETX, EOT 

HT, LF, VT, FF 

All characters between NUL & US not listed 

above 


4 


Delay Timer 







1-255 


Disabled 

Period of TXD cct inactivity before data 
forwarded (1/20 of a second). The minimum 
time-out is 0.5s. Any value of parameter 4 
between 1 & 10 will default to 0.5s. 


5 


Flow Control from Pad 
(to DTE) 







1 


None 
XON/XOFF 


6 


Service Signals 


5 




1 

5 


Disabled 

Enabled, excluding prompt 

Enabled, including prompt 


7 


Action on Break 


8 


8 


PAD escapes from data transfer state 


11 


Data Rate 


13 


2 

3 

4 

6 

12 

13 

14 


300 bps 

1200 bps 

600 bps 

150 bps 

2400 bps 

4800 bps 

9600 bps 

Other values may be implemented as long as 

they conform to the CCITT/ITU-T 

specifications. 


12 


Flow Control to Pad 
(from DTE) 







1 


None 
XON/OFF 


13 


Line Feed insertion 







1 


None 

LF inserted after CR to DTE 


15 


Character Deletion 







1 


Disabled 
Enabled 



Although not CCITT/ITU-T defined, to be able to specify either X.28 or X.29 modes a Parameter can be used as 
follows. 

For X.28 mode parameter shall be set to 0. 

For the four X.29 variants available, each with a corresponding protocol identifier, the parameter value is set as listed 
below. The identifier octet is supplied with the call request packet when setting up a call. 
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Value 


Description 


Protocol Identifier Octet 


2 


CCITT use 


00000001 


3 


National use 


Olxxxxxx 


4 


International User Bodies 


lOxxxxxx 


5 


DTE - DTE use 


llxxxxxx 



x - this digit may be represented by either a 1 or (to be specified in ITU-T Recommendation X.244). 

8.1 .2 Example mapping of functions between the R reference point and 
the GPRS bearer 

The following example illustrates the case when the PAD functionality is used in the MT. In PAD mode only one PDP 
context can be activated per R reference point. 



TE 



1 . AT command 



4. AT response 



MT 



Urn 



2. GPRS Attach 



3. PDP Context Activation 

* i ► 



NOTE: The 2 ended arrows indicate an exchange of or more messages. 

Figure 4: PAD Service 

1) The TE issues an AT command to activate PAD mode. 

2) If the MS is not yet GPRS attached, the MT performs the GPRS Attach procedure as described in GSM 03.60. 

3) The MT performs the PDP Context Activation as described in GSM 03.60. 

4) The MT sends an AT response to the TE. Following a positive AT response the PAD prompt is issued. 



8.2 



X.25 Packet mode service 



This mode offers a packet based service allowing the application to set up one or more virtual calls using the 
CCITT/ITU-T X.25 procedures. The maximum permitted number of concurrent virtual calls is implementation 
dependent. Both mobile originate and mobile terminate calls are supported. The MT performs a relay function for X.25 
layer 3 which is terminated in the TE. The layer 2 protocol at the R reference point is terminated in the TE and the MT. 

Depending on the application, the TE may or may not incorporate a triple X PAD function. 
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Rref 



TE 


MT 






Application 












GGSN 




Optional 
PAD 












^^25 L3 RELAY/"'' 






X.25 
L3 












LAPB 

or 
other L2 


GPRS Bearer 




LAPB 

or 

other L2 










L1 


L1 

























NOTE: The "other L2" could be GSM 07. 10 or a manufacturer's defined layer 2 

Figure 5: Packet mode 

8.2.1 Layer 1 and Layer 2 options 

This subclause describes standardized layers 1 and 2 which may be used for the TE-MT interface. As an alternative, the 
multiplexing protocol specified in GSM 07.10 or a manufacturer's defined layers 1 and 2 may be used providing they 
meet the requirements for carrying X.25 layer 3 frames over the R reference point. 

8.2.1 .1 Synchronous serial interface 

For TEs with a synchronous serial port - 

Layer 1 is synchronous X.21 or X.21bis (V.24/V.28). 

Layer 2 is LAP B (X.25 L2) based on bit-oriented HDLC. 

NOTE: Configuration of the MT in this case is outside the scope of this specification. 

8.2.1 .2 Asynchronous serial interface 

For TEs with an asynchronous serial port - 
Layer 1 is asynchronous V.24/V.28. 

Layer 2 is LAP B (X.25 L2) based on character-oriented HDLC. 
NOTE: The methods described in ITU-T Rec. V.80 may be applicable here. 



8.2.1.3 



Synchronous and asynchronous (dual mode) interface 



For TEs with a serial port that can operate in both synchronous and asynchronous modes the following mechanism may 
be used where the interface supports AT commands. The interface starts in asynchronous mode and AT commands may 
be used to configure the MT. When configuration is complete, the interface switches to synchronous mode and X.25 
starts up in the usual way. Setting Data Terminal Ready (circuit 108/2) to off is a protocol independent way of returning 
to asynchronous mode. Alternatively, the closing down of LAP B could be used as the signal. 
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8.2.2 Example mappings of functions between the R reference point and 
the GPRS bearer 

The minimum requirement is that the MT shall be GPRS -attached and the X.25 context activated whilst an X.25 virtual 
call is in progress. Any extension to this requirement depends on whether the MT implements any other GPRS- 
supported services (e.g. SMS) which might require that the MT remains GPRS-attached even when there is no X.25 
virtual call in progress. 

The following subclauses describe only the X.25 requirements. These actions may be filtered by the requirements of any 
other GPRS -supported service. For example, if a GPRS-only MT also supports SMS, a request for 'disconnection' of the 
X.25 service would result in a deactivation of the X.25 context but not a GPRS-detach. 

8.2.2.1 Standardized X.25 TE 

This case applies to TEs which implement only the X.25 procedures, i.e. they have no support for AT commands. The 
layer 1 and 2 options described in subclause 8.2.1.1 and 8.2.1.2 apply. 

Because of the different implementations of X.25 procedures in existing DTEs, attach/detach and activate/deactivate 
may need to be controlled at layer 1, 2 or 3 of the X.25 interface. Whilst it is always possible to use layer 3 control, this 
requires the most complete implementation of the X.25 protocol stack in the MT. Control at a lower layer may result in a 
simpler implementation. The procedures for connection and disconnection at all three layers are described in 
CCITT/ITU-T X.25. 

In all cases it may be desirable to incorporate a timer to delay the deactivate/detach procedures in order to avoid 
excessive changes of the activation and attachment states in the course of a number of consecutive calls. 

NOTE: The activation and deactivation of an X.25 context to carry packets over GPRS is analogous to setting up 
and clearing a switched ISDN B channel connection to carry them over an ISDN. The call control 
mapping procedures used in the ISDN case are described in detail in ITU-T X.31 clause 7.3 (layer 1) and 
appendix I (layers 2 and 3). 

8.2.2.1.1 Layer 1 control 

This applies to X.25 DTEs which disconnect at the physical layer when no virtual calls are in progress. The TE and MT 
signal to one another by using V.24 or X.21 control signals. 

From TE - 

Physical layer connect received by MT -> attach, activate 

Physical layer disconnect received by MT -> deactivate, detach 

From network - 

If the X.25 context is not currently active, an attempt by the network to offer a mobile terminated X.25 virtual 
call will be signalled by the receipt at the MT of a Request PDP Context Activation message. The MT signals 
this to the TE by using V.24 or X.21 control signalling and, if successful, -> attach, activate. 

A network request that the X.25 context should be deactivated or a failure of the radio link will result in the MT 
performing a physical layer disconnect. 

8.2.2.1.2 Layer 2 control 

This applies to X.25 DTEs which keep layer 1 active but disconnect at the data link layer when no virtual calls are in 
progress. The TE and MT signal to one another by starting and stopping the data link layer protocol. 

From TE - 

Data link layer set-up received by MT -> attach, activate 

Data link layer disconnect received by MT -> deactivate, detach 
From network - 
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If the X.25 context is not currently active, an attempt by the network to offer a mobile terminated X.25 virtual 
call will be signalled by the receipt at the MT of a Request PDP Context Activation message. The MT signals 
this to the TE by attempting to start the data link layer and, if successful, -> attach, activate. 

A network request that the X.25 context should be deactivated or a failure of the radio link will result in the MT 
performing a data link layer disconnect. 

8.2.2.1.3 Layer 3 control 

This applies to X.25 DTEs which keep layers 1 and 2 active when no virtual calls are in progress. 

From TE - 

Call Request packet received by the MT -> attach, activate 

(Action is taken only if there are no X.25 virtual calls already in progress) 

Clear Confirmation packet received by the MT from the TE -> deactivate, detach 
(Action is taken only if there are no more X.25 virtual calls in progress.) 

From network - 

If the X.25 context is not currently active, an attempt by the network to offer a mobile terminated X.25 virtual 
call will be signalled by the receipt at the MT of a Request PDP Context Activation message. Following 
activation by the MT, an X.25 Call Request packet will be received from the network. 

Clear Confirmation packet received by the MT from the network -> deactivate, detach 
(Action is taken only if there are no more X.25 virtual calls in progress.) 

A network request that the X.25 context should be deactivated or a failure of the radio link will result in the MT 
clearing any outstanding X.25 virtual calls. 

The above refer only to normal clearing situations. An actual implementation shall take into account exceptional 
conditions such as the receipt of a Clear Request packet from the TE but no acknowledging Clear Confirmation from the 
network. 

8.2.2.2 X.25 TE with support for AT commands 

This case applies to TEs which implement AT commands in addition to supporting X.25 procedures. The layer 1 and 2 
options described in subclauses 8.2.1.2 and 8.2.1.3 apply. 

The TE sends GPRS AT commands to configure the MT, followed by a command to switch the interface into packet 
mode and start X.25. A mode of operation may be supported which provides compatibility with existing modem dial 
procedures. 
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IP Based Services 



All protocols that are supported by the underlying IP protocol are applicable in the GPRS environment. However there 
may be some limitations due to the RF environment. 

The IP protocol can be run over various underlying protocols as shown in the following figure. 
TE R ref MT 



Applic. 



IP 



L2/PPP 



L1 



L2/PPP 



L1 



GPRS Bearer 



Figure 6: IP Based Services 

PPP is a widely supported protocol in numerous operating systems and this alleviates the need for any GPRS specific 
protocol at the TE. PPP at the MT shall comply with the following specifications IETF STD 51 (RFC 1661, RFC 1662), 
RFC 1570, RFC 1989, and RFC 1332. The Domain Name Server information shall be delivered as defined in RFC 
1877. The delivery of vendor-specific packets and options shall conform to RFC 2153. 

As an alternative to PPP, an L2 protocol can be used which is defined as a manufacturer's operating system dependent 
protocol capable of carrying IP frames over the R reference point. 

9.1 Example mapping of functions between the R reference 
point and the GPRS bearer for IP over PPP 

The following example illustrates the case when the IP over PPP functionality is used in the MT. The example does not 
include all the details of PPP, but only describes the logical operation of PPP connection establishment, host 
authentication and IP configuration. 

Each interface at the R reference point can support only one PPP connection and each PPP connection can support only 
one IP session. Therefore, in PPP mode only one IP PDP context can be activated per interface at the R reference point. 
However, it is possible for a PCMCIA card (or other multiplexed interface) to support multiple virtual interfaces 
(communications ports) at the R reference point. Multiple PPP connections and IP contexts are possible in this case. 
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TE 



MT 



Um 



I 
I 
I 
I 

1. AT command 




2. AT response 




3. LCP Conficjure-Request 




4. LCP Configure Ack 




5. LCP Configure-Request 




6. LCP Configjjre Ack 




7. Host authentication 




8. NCP Configure-Request 


9. GPRS Attach 


i 
i 
i 
i 

i 

1 1 . NCP Configure Ack 


1 0. PDP content Activation 









Figure 7: IP Over PPP Based Service 

1) The TE issues AT commands to set up parameters and enter PPP mode (refer to subclause on AT commands for 
further details). 

2) The MT sends AT responses to the TE. 

3) The PPP protocol in the TE sends a LCP Configure-Request. This command is to establish a PPP link between 
the TE and the MT. 

4) The MT returns LCP Configure-Ack to the TE to confirm that the PPP link has been established. The MT might 
previously have sent a LCP Configure-Nak in order to reject some options proposed by the TE. This in turn 
might have triggered a retransmission of the LCP Configure-Request with different options. 

5) The PPP protocol in the MT sends a LCP Configure-Request in order to negotiate for the authentication protocol 
used for authentication of the host TE towards the MT. The MT shall initially negotiate for CHAP, and if this is 
unsuccessful, for PAP. 
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6) The TE returns a LCP Configure- Ack to the MT to confirm the use of the specified authentication protocol. The 
MT might previously have sent a LCP Configure-Nak in order to reject the protocol proposed by the TE. This in 
turn might have triggered a retransmission of the LCP Configure-Request with different options. 

7) If the negotiated authentication protocol is either of CHAP or PAP, the TE authenticates itself towards the MT by 
means of that protocol. The MT stores the necessary authentication data and sends a locally generated positive 
acknowledgement of the authentication to the TE. If none of the protocols is supported by the host TE no 
authentication shall be performed. Refer to GSM 09.61 for further details on the authentication. 

8) The PPP protocol in the TE sends to the MT a NCP Configure-Request. This command activates the IP protocol. 

9) If the MS is not yet GPRS attached, the MT performs the GPRS Attach procedure as described in GSM 03.60. 

10) The MT performs a PDP Context Activation as described in GSM 03.60. IP configuration parameters may be 
carried between the MT and the network in PDP Context Activation messages. 

11) The MT acknowledges to the PPP protocol in the TE that the IP protocol is now activated by sending a NCP 
Configure- Ack command. Before sending a NCP Configure- Ack, the MT might previously have sent a NCP 
Configure-Nak in order to reject some IP parameters proposed by the TE. This in turn might have triggered a 
retransmission of the NCP Configure-Request with different parameter values. NCP Configure-Ack may also 
carry IP protocol related parameters such as dynamic IP address to the TE. The MT shall also pass name server 
information to the TE if the TE has requested for it and if this information is provided by the GGSN. Other 
packet types and options may optionally be delivered. 
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10 



PPP Based Services 



By means of the PDP type 'PPP' GPRS may support interworking with networks based on the point-to-point protocol 
(PPP), as well as with networks based on any protocol supported by PPP through one of its Network Control Protocols 
(NCPs). It may also support interworking by means of tunnelled PPP, by e.g. the Layer Two Tunnelling Protocol 
(L2TP). The protocol configuration is depicted in figure 8. 
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GGSN 



Gi ref 













Application 






L3 




^^--__ ^^-^ 


PPP 


PPP 




■*-- 










*- 


"\^ 






L2 


L2 


GPRS Bearer 




L1 


L1 











Figure 8: PPP Based Services 

The 'L3' protocol is a network layer protocol supported by one of the PPP NCP's. All protocols currently supported by 
NCP's are listed in [36]. 



The PPP is a widely supported protocol in numerous operating systems and this alleviates the need for any GPRS 
specific protocol at the TE. PPP at the GGSN shall comply with [34]. The Domain Name Server information shall be 
delivered as defined in [40]. The delivery of any vendor-specific packets and options shall conform to [41]. 



The 'L2' protocol may be the link layer protocol defined for the PPP suite [35]. As an alternative an L2 protocol can be 
used which is defined as a manufacturer's operating system dependent protocol capable of carrying PPP frames over the 
R reference point. 

10.1 Example mapping of functions between the R reference 
point and the GPRS bearer 

The following example illustrates the case when the PPP negotiation is carried out between the TE and the GGSN. The 
example does not include all the details of PPP, but only describes the logical operation of PPP LCP, host authentication 
andPPPNCP. 
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TE 
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1. AT command 
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2. PDP context Activation 
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4. LCP Configure-Request 
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6. LCP Configure-Request 



7. LCP Configure Ack 
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9. NCP Configure-Request 



11. NCP Configure Ack 



Figure 9: PPP Based Service 

1) The TE issues AT commands to set up parameters and activate a PDP Context (refer to sub-clause on AT 
commands for further details). 

2) The MT performs a PDP Context Activation as described in GSM 03.60. 

3) The MT sends AT responses to the TE. 

4) The PPP protocol in the TE sends an LCP Configure-Request. This command establishes a PPP link between the 
TE and the GGSN. 

5) The GGSN returns an LCP Configure-Ack to the TE to confirm that the PPP link has been established. The 
GGSN might previously have sent an LCP Configure-Nak in order to reject some options proposed by the TE. 
This in turn might have triggered a retransmission of the LCP Configure-Request with different options. 

6) The PPP protocol in the GGSN sends an LCP Configure-Request in order to negotiate for the authentication 
protocol used for authentication of the host TE towards the GGSN. 

7) The TE returns an LCP Configure- Ack to the GGSN to confirm the use of the specified authentication protocol. 
The GGSN might previously have sent an LCP Configure-Nak in order to reject the protocol proposed by the TE. 
This in turn might have triggered a retransmission of the LCP Configure-Request with different options. 

8) The TE authenticates itself towards the GGSN by means of the negotiated protocol. If no authentication protocol 
can be negotiated the GGSN may reject the PPP connection. Refer to GSM 09.61 for further details on the 
authentication. 

9) The PPP protocol in the TE sends to the GGSN an NCP Configure-Request. This command activates the network 
layer protocol. 

10) The GGSN acknowledges to the PPP protocol in the TE that the network layer protocol is now activated by 
sending an NCP Configure- Ack command. Before sending an NCP Configure-Ack, the GGSN might previously 
have sent an NCP Configure-Nak in order to reject some parameters proposed by the TE. This in turn might have 
triggered a retransmission of the NCP Configure-Request with different parameter values. 
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1 1 Internet Hosted Octet Stream Service (IHOSS) 
11.1 Introduction 

This section describes the MS aspects of the GPRS Internet Hosted Octet Stream Service (IHOSS). This is a MO-only, 
connection-oriented service that carries an unstructured octet (character) stream between a GPRS MS and an Internet 
Host. 

IHOSS uses OSPTHOSS which is a subset of the Octet Stream Protocol (OSP) PDP type to provide a 'character pipe' 
between the MS and the GGSN. In the GGSN there is a relay function between the OSP and the Internet Host protocol 
(usually TCP). An annex to this specification contains the generic description of OSP. The features of OSP that are used 
by OSP:IHOSS are described later in this section. 

Figure 10 shows the scope of IHOSS and OSPTHOSS. 




moss OSPTHOSS 



Figure 10: Scope of the Internet Hosted Octet Stream Service and Octet Stream Protocol 

1 1 .2 Example of protocol stacks at the MT 

Figure 1 1 shows an example of the protocol stacks at the MT. The MT contains a relay function between OSP and an 
asynchronous character interface. 
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Figure 11 : Example of protocol stacks for an MT with an asynchronous serial interface 
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1 1 .3 IHOSS connection control and OSP PDP context 
management 

Establishing an IHOSS connection involves setting up two segments, the PLMN segment (using the OSP) between the 
MS and GGSN, and the Internet segment between the GGSN and the Internet Host. There is a one-to-one mapping 
between the PLMN segment of an IHOSS connection and an OSP:IHOSS context. When the IHOSS connection is 
established, an OSP PDP context is activated. When the connection is released, the context is deactivated. It is possible 
for a suitably designed MT to activate multiple simultaneous OSP PDP contexts (subject to any limits imposed by the 
GPRS network), each context supporting one IHOSS connection. 

1 1 .3.1 Connection establishment and PDP context activation 

Establishing the PLMN segment of an IHOSS connection follows the normal procedures for PDP context activation 
described in GSM 03.60 using messages described in GSM 04.08 (MS-SGSN) and GSM 09.60 (SGSN-GGSN). Figure 
12 illustrates the procedure when TCP is used over the Internet. 



Activate PDP context request 



MS SGSN 

Figure 12: IHOSS connection establishment 

The MS requests that an OSP PDP context be set up by sending an Activate PDP context request message. The PDP 
type is set to OSPTHOSS. The PDP configuration options may provide information to enable the GGSN to set up a 
connection to the Internet host. (Alternatively this information may be derived from subscription information in the HLR 
and configuration information within the GGSN.) 

In the case where TCP is used over the Internet, the response accepting the context activation request is returned to the 
MS only when the TCP connection to the Internet host has been established. If the TCP connection attempt fails, an 
Activate PDP context reject message is returned. 

In the case where UDP is used over the Internet, the response accepting the context activation request is returned to the 
MS only when at least a successful DNS lookup of the Internet host name has been completed. If the lookup fails, an 
Activate PDP context reject message is returned. (The GGSN may perform additional checks before responding to the 
context activation request.) 

The format of the Activate PDP context request message is shown below: 

Activate PDP Context Request ( 

NSAPI = generated within MS, 

PDP type = OSP:IHOSS, 

PDP address = null, 

APN = as required or null - this may be provided by the HLR, 

QoS requested = as defined in the generic OSP specification or null - this may be provided by the HLR, 

PDP configuration options = (Internet hostname, port number, protocol type, maximum GGSN buffer sizes, OSP 

version number - all optional) 

) 

The format of the PDP configuration options is described in a later section. 
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1 1 .3.2 Connection release and PDP context deactivation 

When the IHOSS connection is released the OSP:IHOSS context is deactivated. The disconnection can be originated 
either by the MT or the Internet host, or exceptionally by the SGSN under fault conditions. The MT initiates 
disconnection by sending a Deactivate PDP context request. This is acknowledged by the receipt of a Deactivate PDP 
context accept which indicates that the Internet connection has been cleared. An Internet host or SGSN initiated 
disconnection is signalled to the MT by the receipt of a Deactivate PDP context request which it acknowledges by 
sending a Deactivate PDP context accept. 

11.4 OSP:IHOSS subset of OSP 

11 .4.1 Required features 

The following features of OSP are required for the OSP:IHOSS subset of OSP: 

11.4.1.1 User data transport 

This is as specified in the generic OSP description 

11.4.1.2 Flow control 

This shall map on to the local flow control mechanism at the DTE-MT interface. 

1 1 .4.2 Optional features 

The following features of OSP are optional for the OSPTHOSS subset of OSP: 

11.4.2.1 Break handling 

The OSP break procedure may be mapped on to the local break mechanism at the DTE-MT interface. 

1 1 .4.2.2 Packet Assembler/Disassembler 

If the DTE-MT interface is character-oriented, a PAD is required in the OSP entity in the MT. The PAD may have pre- 
set values for the forwarding criteria parameters or they may configurable using, for example, an AT command. 

If the interface to the application is block-oriented, for example in an embedded system, the PAD function is not needed. 

1 1 .4.2.3 GGSN maximum buffer size negotiation 

Although the OSP entity in the GGSN does not have a PAD, it still requires buffers to hold the relayed packets. The 
following GGSN PAD parameters (in the Protocol Configuration Options) may be used to specify the maximum buffer 
sizes for the two directions of data transfer. 

PAD Parameter Direction 

Assembly buffer max size (253) GGSN to MS 

Disassembly buffer max size (254) MS to GGSN 

1 1 .4.3 Not-required features 

The following features of OSP are not required for the OSPTHOSS subset of OSP: 

Control block transport 

Remote configuration of OSP PAD in the GGSN (appart from the optional GGSN buffer size configuration - see above). 

OSP protocol version negotiation (OSP:IHOSS uses the default version (0) of OSP.) 
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1 1 .5 Protocol option parameters 



All these parameters in the PDP context activation request are optional. If not provided by the MT, this information may 
be derived from subscription information in the HLR and configuration information within the GGSN. The parameters 
use the syntax described in GSM 04.08. 

11.5.1 Hostname 

This refers to the Internet host to which the connection will be made. 

Option ID 128 

Lengthnumber of characters in the Hostname 

Contents an IA5 character string which is the fully formed domain name extended hostname. 

11.5.2 Port Number 

This refers to the TCP or UDP port on the host identified by Hostname, which forms the endpoint of the Internet side of 
the connection. 

Option ID 129 

Lengthnumber of characters in the Port Number 

Contents an IA5 character string which is the Port Number in decimal. 

Note. If no port number is specified, a default value of 23 is used by the GGSN. 

1 1 .5.3 Protocol Type - TCP or UDP 

This refers to the protocol used over IP on the GGSN to Internet host segment of the connection. The options available 
are Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). 

Option ID 130 

Length 3 

Contents an IA5 character string which is either "TCP" or "UDP". All other values are reserved. 

If no Protocol Type is specified, TCP is used by the GGSN. 

1 1 .5.4 GGSN PAD parameters (maximum buffer sizes only) 

The GGSN PAD options parameter is described in the generic OSP specification. 



12 AT commands 



GSM 07.07 defines commands that a TE may use to control a GPRS MT via a non-multiplexed character-stream 
interface. This places certain limitations on the functionality of the interface. For example, it is not possible for the MT 
to send control information to the TE or for the TE to send commands to the MT whilst the interface is in the V.250 
online data state unless the layer 2 protocol itself supports this feature. However, a manufacturer-specific escape 
mechanism may be provided to enable the TE to switch the MT into the V.250 online command state. The use of a 
multiplexed interface, for example that specified in GSM 07.10, is not considered here. 

It is anticipated that GPRS MTs will vary widely in functionality. At one extreme, a class A MT might support multiple 
PDP types as well as circuit switched data, and use multiple external networks and QoS profiles. At the other extreme a 
class C MT might support only a single PDP type using a single external network, and rely on the HLR to contain the 
context definition. 
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A comprehensive set of GPRS-specific AT commands is defined in GSM 07.07 to provide the flexibility needed by the 
more complex MT. The commands are designed to be expandable to accommodate new PDP types and interface 
protocols, merely by defining new values for many of the parameters. Multiple contexts may be activated if the interface 
link-layer protocol is able to support them. The commands use the extended information and error message capabilities 
described in GSM 07.07. 

For MTs of intermediate complexity, most commands have simplified forms where certain parameters may be omitted. 

For the simplest MTs, and for backwards compatibility with existing communications software, it is possible to control 
access to the GPRS using existing modem-compatible commands. A special dial-string syntax is defined for use with the 
D command. This "modem compatible" mode of operation is described in GSM 07.07. 

Subclause 10.2 contains examples of command sequences for a number of applications. 

Annex A of this document lists the AT commands for GPRS. They are fully defined in GSM 07.07, 

12.1 General on AT commands 

The following sections describe how the AT commands are used for GPRS. The AT commands themselves are fully 
described in GSM 07.07. Reference to the particular AT command names are shown only for clarity. In all case refer to 
GSM 07.07 for the latest descriptions. 

12.1 .1 Interaction of AT commands, GPRS management and PDPs 

State machines may be used to describe the behaviour of - 

AT commands (ITU-T V.250). 

GPRS PDP context management (GSM 03.60). 

PDP startup, data transfer and termination (Packet Data Protocol specifications). 

The layer 2 protocol (if any) used across the TE-MT interface (layer 2 protocol specifications). 

This subclause does not attempt to describe in detail how these state machines interact but rather to give some general 
guidance on their relationships. 

12.1.1.1 AT commands and responses 

AT commands may be issued and responses received by the TE only when the TE and MT are in V.250 command state. 

The possibility of suspending the PDP and/or layer 2 protocol and entering V.250 online command state is not 
considered here; neither is the use of a multiplexed interface where the PDP and the AT commands use separate logical 
channels. 

12.1.1.2 PDP and layer 2 protocol operation 

The PDP (across the TE-MT interface) may startup, transfer data and terminate only when the TE and MT are in V.250 
online data state. It may be necessary to startup a layer 2 protocol across the interface before starting the PDP. The PDP 
startup procedure may provide information needed for the PDP context activation procedure (see 10.1.1.3.2). 

12.1.1.3 GPRS management 

A particular PDP may be used to transfer data only when a context is active for that PDP. Before a context can be 
activated, the MT must be attached to the GPRS network. 

In order to provide flexibility and support a variety of types of GPRS MT and PDP, AT commands are provided which 
give the TE explicit control over attachment and detachment (+CGATT), and context activation and deactivation 
(+CGACT) procedures. These commands allow the TE to retain control of the MT, and receive status information from 
the MT, after these actions have been performed. 
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12.1.1.3.1 GPRS attachment 

The MT may be attached and detached using the +CGATT command. However, it may not be necessary to use the 
command since attachment may occur - 

on power up or reset; 

when an attempt is made to activate a context either explicitly (+CGACT) or as a result of a PDP startup procedure; 

when the mobile class is changed (+CGCLASS). 

Similarly, detachment may occur - 

as a result of a PDP termination procedure (if no other GPRS services are active); 

when the mobile class is changed (+CGCLASS). 

12.1.1.3.2 PDP context activation 

Certain information must be provided to the network in order for a context activation attempt to be successful. The TE 
may provide some of this information to the MT during the PDP startup procedure rather than through AT command 
procedures. In this case the context activation cannot be initiated by the +CGACT command but rather on receipt of the 
appropriate information during the PDP startup. 

12.1 .2 Use of default context parameter values 

The activate context request message sent by the MT to the network contains a number of parameters whose values can 
usefully be set by the TE. Under certain circumstances the values for some or all of the parameters need not be provided 
by the TE, either via AT commands or the PDP startup procedure. The storage of context information in the SIM is not 
considered in this specification. Rules concerning what values shall be sent by the MT to the network under various 
circumstances are given in 03.60. 

One particular rule that is designed to simplify operation in modem compatibility mode is that if there is only one PDP 
context subscription in the HLR then all of PDP type, PDP address and APN may be omitted. 

12.1.2.1 PDP type 

This may be omitted: 

when the MT supports only one PDP type (it will be provided by the MT); 
or according to the rules given in 03.60. 

12.1.2.2 PDP address (of the MS) 

This shall be omitted when: 

a dynamic address is required; 

or according to the rules given in 03.60. 

1 2.1 .2.3 Access Point Name 

This may be omitted: 

according to the rules given in 03.60. 

12.1.2.4 QoS Requested 

This may be omitted when: 

the default subscribed QoS is acceptable. 
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12.1.2.5 PDP Configuration Options 

These shall be omitted: 

when none are required for the PDP concerned; 
or according to the rules given for the PDP. 



1 2.2 Example command sequences for dial-compatibility mode 
12.2.1 PPP in dial compatibility mode 



12.2.1.1 



Mobile initiated IP context activation 



In this mode of operation, the MT behaves like an originating modem and accepts the normal V.250 commands 
associated with placing and clearing a call to a dial-up PPP server. Although the procedures for setting up the IP context 
are initiated from the mobile end, IP-based sessions, for example the File Transfer Protocol (FTP), may be initiated from 
either end once the context is active. 

For this example it is assumed that 

- the user has subscribed to only one PDP context (of type IP) and therefore no context parameter values are needed, 

- the MT supports only PPP at the MT-TE interface and therefore no layer 2 protocol need be specified. 
A possible sequence of events is - 

The MT begins in V.250 command state. 

TE -> MT: AT<GPRS -specific configuration commands, if required> 

MT -> TE: OK 

The TE sends a dial command requesting the GPRS. 

TE -> MT: ATD*99# 

MT -> TE CONNECT 

The MT enters V.250 online data state. 

TE starts up PPP (LCP exchange) - 
TE -> MT: LCP Configure-request 
MT -> TE: LCP Configure-ack 

PPP Authentication may take place (optional) 

TE starts up IP (NCPfor IP exchange) - 

TE -> MT: NCP(IP) Configure-request 

MT <-> network: MT performs the GPRS-attach procedure if the MT is not currently attached. 

MT <-> network: MT performs the IP context activation procedure. 

MT -> TE: NCP(IP) Configure-ack 

TE <-> MT< - > network: IP packets may now be transferred 

TE stops IP (optional) - 

TE-> MT: NCP(IP) Terminate-Request ) this 

MT<-> network: MT performs the IP context deactivation procedure ) is 

MT -> TE: NCP(IP) Terminate-Ack ) optional 

TE stops PPP - 

TE-> MT:LCP Terminate-Request 

MT <-> network: MT performs the IP context deactivation procedure if it has not already done so. 
MT <-> network: MT may perform the GPRS-detach procedure if no other GPRS services are active. 
MT -> TE: LCP Terminate-Ack 
The MT returns to V.250 command state and issues the final result code - 
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MT -> TE NO CARRIER 

The TE may recognise this as a return to V.250 command state. However, if it is using procedures intended for 
controlling modems, it may attempt to force a disconnect since in the modem case it cannot rely on the remote modem 
dropping the carrier. It will use some combination of - 

TE -> MT: TE drops circuit 108/2 (Data Terminal Ready) 

TE -> MT: escape sequence (e.g. +++) 

TE -> MT: ATH 

The MT should respond according to V.250 even if it is already in command state. 

If the connection is lost at any time, the MT shuts down PPP, returns to V.250 command state and issues the final result 
code - 

MT -> TE NO CARRIER 

1 2.2.1 .2 Network requested IP context activation 

In this mode of operation, the MT behaves like an answering modem and accepts the normal V.250 commands 
associated with answering a call to a PPP server. Although the procedures for setting up the IP context are initiated from 
the network end, IP-based sessions, for example the File Transfer Protocol (FTP), may be initiated from either end once 
the context is active. 

Two example sequences of events are given, for the cases of automatic and manual answering - 

Case 1: automatic answering 

The MT begins in V.250 command state. 

TE -> MT: AT<GPRS -specific configuration commands, if required > 

The TE sets automatic answering mode - 

TE -> MT: ATS0=1 

MT <- > network: MT performs the GPRS-attach procedure if the MT is not currently attached. 

Subsequently - 

network -> MT: Request PDP Context Activation message 
MT -> TE: RING 

The MT returns the intermediate result code - 

MT -> TE CONNECT 

- and enters V.250 online data state. 

The TE and MT perform the PPP and IP startup procedures which include the MT requesting the network to activate 
the IP context. 

Case 2: manual answering 

The MT begins in V.250 command state. 

TE -> MT: AT<GPRS -specific configuration commands, if required > 

The TE sets manual answering mode and requests a GPRS-attach (if necessary) - 

TE -> MT: ATS0=0 

TE -> MT: AT+CGATT= 1 

MT <- > network: MT performs the GPRS-attach procedure if the MT is not currently attached. 



ETSI 



(GSM 07.60 version 7.0.0 Release 1 998) 33 ETSI TS 1 01 356 V7.0.0 (1 999-07) 

network -> MT: Request PDP Context Activation message 

MT -> TE: RING 

The TE answers manually, - 

TE -> MT: ATA 

MT -> TE CONNECT 

- and enters V.250 online data state. 

The TE and MT perform the PPP and IP startup procedures which include the MT requesting the network to activate 
the IP context. 

or the TE rejects the connection - 

TE -> MT: ATH 

- and remains in V.250 command state 

12.2.2 MO X.25 virtual call using a triple-X PAD in dial compatibility mode 

This example shows how the <called_address> string maybe used in the D command to make an X.25 call to a 
specified X. 121 address. 

The MT begins in V.250 command state. 

TE -> MT: AT<GPRS -specific configuration commands, if required> 

MT -> TE: OK 

The TE sends a dial command requesting the GPRS to X.121 address 1234567890. 

TE->MT: ATD*99*1234567890# 

MT -> TE CONNECT 

The MT enters V.250 online data state, performs a GPRS attach if necessary and activates the X.25 context. It then 
automatically makes an X.25 call to the specified address, bypassing the PAD prompt. If the call is successful the MT 
responds with the PAD connect message - 

1234567890 COM 
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Annex A (informative): 

Summary of AT commands for GPRS 

This informative annex lists the AT commands for GPRS that are fully described in GSM 07.07. 

Table A.1 : Summary of AT commands for GPRS 



Command 


Description 


+CGACT 


PDP context activate or deactivate 


+CGANS 


Manual response to a network request for PDP 
context activation 


+CGATT 


GPRS attach or detach 


+CGAUTO 


Automatic response to a network request for PDP 
context activation 


+CGCLASS 


GPRS mobile station class 


+CGCLOSP 


Configure local Octet Stream PAD parameters 


+CGCLPAD 


Configure local triple-X PAD parameters 


+CGDATA 


Enter data state 


+CGDCONT 


Define PDP context 


+CGEREP 


Control unsolicited GPRS event reporting 


+CGPADDR 


Show PDP address 


+CGREG 


GPRS network registration status 


+CGQMIN 


Quality of service profile (minimum acceptable) 


+CGQREQ 


Quality of service profile (requested) 


+CGSMS 


Select service for MO SMS messages 



Table A.2: Summary of GPRS Extensions to existing GSM AT commands 



Command 


Description 


+CEER 


Extended error report (refer to 07.07) 


+CMEE 


Report mobile equipment error (refer to 07.07) 


+CR 


Service reporting control (refer to 07.07) 


+CRC 


Cellular result codes (refer to 07.07) 







Table A.3: Summary of AT commands for GPRS modem compatibility mode 



Command 



SO 



Description 



Answer - manual acceptance of a network request for 
PDP context activation 



Dial - request GPRS service 



On-hook - manual rejection of a network request for 
PDP context activation 



Automatic answering control - automatic acceptance 
of a network request for PDP context activation 
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Annex B (informative): 

Octet Stream Protocol (OSP) PDP type 

B.1 Scope 

The Octet Stream Protocol (OSP) is used to carry an unstructured octet (character) stream between the MS and GGSN. 
It is used to provide a 'character pipe' to allow a MS to communicate (via the GGSN) with an arbitrary Internet host, or 
other character-based service. Unlike PDP types such as IP and X.25, OSP has no existence outside the PLMN. In the 
MS there is a character stream at the R reference point together with some optional control signals. In the GGSN there is 
a relay function, carrying the same character stream and control signals between the OSP entity and a fixed network 
protocol stack. 

An OSP entity has two modes of operation. In octet mode, it uses a Packet Assembly function to assemble a number of 
user octets into a single packet for more efficient transport by the underlying packet protocol. A complementary Packet 
Disassembly function in the same OSP entity performs the reverse operation. In block mode, an OSP entity's Packet 
Assembly and Disassembly functions are bypassed. Data is transferred between the OSP user and the OSP entity in 
blocks of octets. Each block of octets is carried in a single packet of the underlying protocol. The selection of octet or 
block mode is made independently for each OSP entity as an implementation or configuration decision before a 
connection is established and remains fixed for the duration of that connection. 

An example of the use of block mode is when OSP is used for interworking with a fixed network where the octet stream 
is also carried in packets. The use of the block mode in the OSP entity in the GGSN avoids the use of back-to-back 
PADs. Block mode could also be used in a MS where the MT function is embedded in a larger piece of equipment and 
the application transfers data in blocks of octets. 

OSP uses the services of SNDCP between the MS and SGSN, and the services of GTP between the SGSN and GGSN. 
The Quality of Service is determined mainly by that provided by the underlying layers. However, the end-to-end delay 
may be affected by the presence of the PAD (Packet Assembler/Disassembler) function. For most applications it is 
anticipated that a reliable (acknowledged) service will be provided by the underlying layers. 

In summary, the main functions of OSP are: 

transport of an unstructured octet stream, 
- Packet Assembly/Disassembly (to make efficient use of network resources), 

end-to-end flow control. 
In addition OSP may provide: 

transport of a 'break signal, 

transport of blocks of control information between the OSP users, 

user control of packet assembly buffer forwarding, 

direct OSP user access to the underlying packet service, bypassing the PAD. 
Figure B.l shows how OSP fits into the overall GPRS protocol model. 
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MT 



BSS 



SGSN 



GGSN 



Figure B.1 : Relationship of OSP to the rest of the GPRS protocol architecture 



B.2 Service primitives 

B.2.1 Service Primitives provided by the OSP layer 

The service provided by the OSP layer to its user (the layer above) is described in terms of service primitives. An 
example of the use of the OS-DATA.request and OS-DATA. indications primitives to transfer an octet or block of octets 
from one OSP user to another is shown in figure B.2. 



Sending 
OSP user 



OS-DATA.request 

1 




Receiving 
OSP user 



t 



OS-DATA, indication 




Figure B.2: An example of the use of the OS-DATA primitives 

The primitives provided by the OSP layer are listed in Table B.l. 
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Table B.1 : OSP layer service primitives 



Generic 
Name 


Type 


Parameters 


Request 


Indication 


Response 


Confirm 


OSP User (MS or GGSN) <— > OSP 


OS -DATA 


X 


X 






D-PDU (single octet or 
block of octets) 


OS-UNITDATA 


X 


X 






D-PDU (single octet or 
block of octets) 


OS-FLOWCONTROL 


X 


X 






Requested flow control 
state (STOP or START) 


OS-BREAK 


X 


X 


- 


- 


none 


OS -CONTROL 


X 


X 


- 


- 


C-PDU (block of octets) 


OS -FORWARD 


X 


- 


- 


- 


none 



B.2.1.1 OS- DATA, request 

Request used by the OSP user for transmission of a D-PDU. In octet mode, the D-PDU consists of a single octet. In 
block mode the D-PDU consists of a block of octets. This primitive is used when the underlying protocol layers are 
providing a reliable service. 

B.2.1.2 OS-DATA.indication 

Indication used by the OSP entity to deliver the received D-PDU to the OSP user. In octet mode, the D-PDU consists of 
a single octet. In block mode the D-PDU consists of a block of octets. 

B.2.1.3 OS-UNITDATA.request 

Request used by the OSP user for transmission of a D-PDU. In octet mode, the D-PDU consists of a single octet. In 
block mode the D-PDU consists of a block of octets. This primitive is used when the underlying protocol layers are 
providing an unreliable service. 

B.2.1.4 OS-UNITDATA.indication 

Indication used by the OSP entity to deliver the received D-PDU to the OSP user. In octet mode, the D-PDU consists of 
a single octet. In block mode the D-PDU consists of a block of octets. 

B.2.1.5 OS-FLOWCONTROLrequest 

Request used by the OSP user for the peer OSP user to update its flow control state. 

B.2.1 .6 OS-FLOWCONTROL.indication 

Indication used by the OSP entity to request the OSP user to update its flow control state. 

B.2.1. 7 OS-BREAK.request 

Request used by the OSP user to send a break signal to the peer OSP user. 
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B.2.1.8 OS-BREAK.indication 

Indication used by the OSP entity to deliver a break signal to the OSP user. 

B.2.1.9 OS-CONTROLrequest 

Request used by the OSP user to request transmission of a C-PDU. The C-PDU consists of a block of octets. The 
reliability of the transmission is determined by the lower layer protocols. 

B.2.1 .1 OS-CONTROL.indication 

Indication used by the OSP entity to deliver a received C-PDU to the OSP user. 

B.2.1. 11 OS-FORWARD.request 

Request used by the OSP user to cause immediate forwarding of the OSP Packet Assembly buffer. 

B.2.2 Service Primitives Used by the OSP Layer 

The OSP layer uses the service primitives provided by the SNDCP layer (see Table B.2) and the GTP layer (see table 
B.3). SNDCP is specified in GSM 04.65 and GTP in GSM 09.60. 

Table B.2: SNDCP service primitives used by the OSP entity 



Generic 
Name 


Type 


Parameters 


Request 


Indication 


Response 


Confirm 


OSP <— > SNDCP 


SN-DATA 


X 


X 


- 


- 


N-PDU, NSAPI 


SN-UNITDATA 


X 


X 






N-PDU, NSAPI, 
protection mode 



B.2.2.1 SN-DATA. request 

Request used by the SNDCP user for acknowledged transmission of an N-PDU. The successful transmission of an SN- 
PDU shall be confirmed by the LLC layer. The SN-DATA.request primitive conveys the NSAPI to identify the PDP 
using the service. 

B.2.2.2 SN-DATA.indication 

Indication used by the SNDCP entity to deliver a received N-PDU to the SNDCP user. Successful reception has been 
acknowledged by the LLC layer. 

B.2.2.3 SN-UNITDATA.request 

Request used by the SNDCP user for unacknowledged transmission of an N-PDU. The SN-UNITDATA.request 
primitive conveys the NSAPI to identify the PDP using the service and protection mode to identify the requested 
transmission mode. 

B.2.2.4 SN-UNITDATA.indication 

Indication used by the SNDCP entity to deliver a received N-PDU to the SNDCP user. 
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Table B.3: GTP service primitives used by the OSP entity 



Generic 
Name 


Type 


Parameters 


Request 


Indication 


Response 


Confirm 


OSP <— > GTP 


GT-DATA 


X 


X 


- 


- 


N-PDU, TID 


GT-UNITDATA 


X 


X 


- 


- 


N-PDU, TID 



B.2.2.5 GT-DATA. request 



Request used by the GTP user for acknowledged transmission of an N-PDU. The successful transmission of an SN-PDU 
shall be confirmed by the TCP layer. The SN-DATA.request primitive conveys TID to identify the PDP using the 



B.2.2.6 GT-DATA. indication 

Indication used by the GTP entity to deliver the received N-PDU to the GTP user. Successful reception has been 
acknowledged by the TCP layer. 

B.2.2.7 GT-UNITDATA.request 

Request used by the GTP user for unacknowledged transmission of an N-PDU. The SN-UNITDATA.request primitive 
conveys TID to identify the PDP using the service. This uses UDP as the path protocol. 

B.2.2.8 GT-UNITDATA.indication 

Indication used by the GTP entity to deliver the received N-PDU to the GTP user. 



B.3 OSP Functional model 



Flow control, D-PDUs OSP 

break, C-PDUs, (octet mode) user 
D-PDUs (block 
mode) , 



Flow control, D-PDUs 

break, C-PDUs, (octet mode), 

D-PDUs (block force forward 
mode) 




Packet 
Disassembler 



OSP 




N-PDUs 



SNDCP or GTP 



N-PDUs 



Figure B.3: OSP functional model 

The main functions of the OSP entity are shown in figure B.3. 
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At the sending side, in octet mode, octets from the OSP user (D-PDUs) are accumulated by the Packet Assembler until 
some forwarding criterion is satisfied. Forwarding can be forced by the user if required. The resulting packet is then 
passed to the multiplexing function (MUX). In block mode, D-PDUs are passed directly to the MUX. The MUX 
combines these packets of user data with flow control requests and optionally break requests and control blocks (C- 
PDUs). (A control block is a delimited set of octets whose maximum size is determined by the limits imposed by the 
underlying protocol.) The resulting stream of N-PDUs is passed to the SNDCP or GTP layer below. 

At the receiving side, the N-PDUs from the SNDCP or GTP layer below are passed to the demultiplexing (DEMUX) 
function. Here the packets of user data, flow control indications, and (if implemented) break indications and control 
blocks (C-PDUs) are separated out. In block mode, the packets of user data are passed directly to the OSP user. In octet 
mode, they are passed to the Packet Disassembler which regenerates the original stream of octets (D-PDUs). 



B.4 OSP N-PDU (packet) format 

Each N-PDU shall contain an integral number of octets, and shall comprise a header part and a data part. An N-PDU 
shall contain data from zero or more D-PDUs or a single C-PDU. (D-PDUs and C-PDUs may not be mixed in the same 
N-PDU.) 

The bit and octet numbering convention used in this specification is illustrated in figure B.4. The bits are grouped into 
octets. The bits of an octet are shown horizontally and are numbered from 1 to 8. Multiple octets are shown vertically 
and are numbered from 1 to N. 



Bit 


8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 




2 








N-l 




Octet N 





Figure B.4: Numbering convention 

N-PDUs are transferred between the OSP layer and the SNDCP or GTP layer in ascending numerical octet order (i.e., 

octet 1,2, ...,N-1,N). 

B.4.1 OSP header 

The OSP header is contained in octet 1. The use of bits 1-4 and bit 8 are described below. Bits 5-7 are not used in this 
version of the protocol and shall be set to zero by the sender and ignored by the receiver. 

B.4. 1.1 Bit 1 - Extension (E) 

This is provided to allow the OSP header in future versions of the protocol to consist of more than one octet. In this 
version of the protocol E shall always be set to 1 by the sender and checked by the receiver. 

B.4.1 .2 Bit 2 - Ready to Receive (RTR) - flow control 

This bit indicates if the OSP entity that sent the N-PDU is able to receive data from its peer OSP entity. 
RTR = not ready to receive 
RTR = 1 ready to receive 
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B.4.1 .3 Bit 3 - Break Request (BR) 

This bit requests that the receiving OSP entity shall signal a break to its user. 
BR = no break 

BR = 1 signal break 

B.4. 1 .4 Bit 4 - Break Acknowledge (BA) 

This bit indicates that the sending OSP entity has signalled a break to its user in response to a Break Request. 
BA = no acknowledge break 

BA = 1 acknowledge break 

B.4. 1 .5 bit 8 - payload type (PT) 

This bit indicates whether the payload contains user data or a control block . 
PT = data (zero or more D-PDUs) 
PT = 1 control (zero or one C-PDU) 

B.4.2 OSP payload 

This consists of one of the following: 

B.4.2. 1 User data 

This consists of zero or more (up to some maximum - TBD) octets of user data (zero or more D-PDUs). 

B.4.2.2 Control block 

This consists of the contents of zero or one C-PDU. 

B.5 Packet Assembly/Disassembly (PAD) function 

In order to make efficient use of the network resources, particularly the radio resource, D-PDUs (octets) received from 
the OSP user are not forwarded immediately but are placed in a buffer. When some forwarding criterion is satisfied, the 
contents of the buffer are forwarded in the payload of an N-PDU to the layer below. At the receiving end, the payload of 
an N-PDU received from the layer below is placed in a buffer and the octets are delivered to the OSP user as a stream of 
D-PDUs (octets). The PAD is used only when the OSP entity is operating in octet mode. It is not used when the OSP 
entity is operating in block mode. 

B.5.1 Packet Assembler 

The packet assembler shall be able to detect the following forwarding criteria. When any one criterion is satisfied, the 
contents of the buffer shall be forwarded in an N-PDU (of type User Data) to the layer below, subject to any flow 
control condition. Whenever a buffer is forwarded, the inactivity timer is stopped (if it is running). 
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B.5.1.1 Buffer full 

The buffer contents are forwarded when the number of octets in the buffer reaches the value of the maximum buffer size 
parameter. 

The maximum N-PDU size is equal to the maximum buffer size plus the size of the OSP header. It should be chosen so 
as to make efficient use of the network resources, particularly the radio resources. Although it is possible to calculate the 
overhead imposed by the various underlying protocol layers, it is not possible to predict exactly how an N-PDU will be 
mapped on to radio frames even if the channel coding is known. This is because the SNDCP layer may use data 
compression, the efficiency of which depends on the compressibility of the data. However, since the SNDCP layer is 
able to segment and reassemble long N-PDUs, it is recommended that the maximum N-PDU size should be several 
times the largest radio frame size, allowing for a typical compression ratio of, say, 2:1. This will ensure that most radio 
frames are full. 

The maximum size for the packet assembly buffer is specified by PAD parameter 253. The value is in the range 1-65535 
octets. 

The maximum size for the packet disassembly buffer is specified by PAD parameter 254. The value is in the range 1- 
65535 octets. 



B.5.1.2 Inactivity timer expiry 

Whenever an octet is placed in the buffer the inactivity timer shall be started, set to the value of the inactivity time 
parameter. When the timer expires, the buffer contents are forwarded. The timer has the following functions: 

1 . to ensure that octets don't remain in the buffer for ever. 

2. to detect significant gaps in the stream of octets and try to ensure that these gaps match the N-PDU boundaries. This 
is beneficial for data that at the user level is in blocks of octets, e.g. a PPP frame. It means that the trailing octets of a 
block do not get delayed (since they are forwarded when the timer expires). Also, because the timer is restarted 
whenever a new octet appears, it ensures that blocks do not get split unless the buffer becomes full. 

3. to give interactive traffic a reasonable response time. 

The inactivity time parameter should be set to be longer than the inter-octet time but shorter than the inter-block time to 
ensure optimum forwarding of blocked data. It shall be possible to set it to an infinite time, i.e. the timer never expires. 

The maximum buffer delay timer is specified by PAD parameter 4 and values shall be in the range 1-255 (units of 1/20 
of a second). Additionally, the value disables the timer. The default value is 0. 

B.5.1 .3 Maximum Buffer Delay timer expiry (optional) 

When the first octet is placed into the (empty) buffer, a maximum buffer delay timer may optionally be started, set to the 
value of the maximum buffer delay parameter. When the timer expires, the buffer contents are forwarded. Thistimer 
ensures that no octet is delayed in the buffer for more than the specified time. 

The maximum buffer delay timer is specified by PAD parameter 255 and values shall be in the range 1-255 (units of 1/2 
of a second). Additionally, the value disables the timer. The default value is 0. 



B.5.1. 4 Special character(s) 



Whenever an octet has been placed in the buffer, it is compared (lower 7 bits only) with a list of 'special characters'. If it 
matches, the buffer is forwarded. 

The possible characters and combinations of characters are specified by PAD parameter 3. Permitted values are listed 
below. 
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Value 


Characters 





disabled 


1 


A-Z, a-z, 0-9 


2 


CR 


4 


ESC, BEL, ENQ, ACK 


8 


DEL, CAN DC2 


16 


ETX, EOT 


32 


HT, LF, VT, FF 


64 


all characeters between NUL and US not listed above 



Values may be added to create further combinations, e.g., 34 (=2+32) corresponds to CR, HT, LF, VT, FF. 

B.5.1 .5 Change in flow control state 

An N-PDU (type User Data) carries flow control information in the OSP header as well as user data in the payload. If 
there is a need to signal a change in the Ready to Receive condition, the buffer shall be forwarded immediately with the 
appropriate (new) value of RTR in the OSP header, unless the change has already been signalled using an N-PDU with 
an empty payload. 

B.5.1 .6 Immediate forwarding request 

When the OSP entity receives a OS-FORWARD. request primitive from its user, it shall immediately forward the buffer 
unless it is empty. 

B.5.2 Packet Disassembler 

The packet disassembler shall forward the contents of the N-PDU (type User data) payload to the OSP user, subject to 
any local flow control condition. 



B.6 Flow control 

The OSP entity maintains two variables indicating the readiness of the local OSP entity (itself) and the remote OSP 
entity (its peer) to receive data. 

Local - variable RTRL 

The value of RTRL is updated as a result of the receipt of OS-FLOWCONTROL.request primitives from the OSP user 
and changes in buffer conditions within the OSP entity. When the user requests STOP, RTRL shall immediately be set 
to 0. When the user requests START, RTRL may be set to 1 immediately or this may be delayed subject to buffer 
conditions. 

The value of RTRL is copied into the RTR bit of every N-PDU transmitted. Whenever RTRL changes, an N-PDU is 
sent immediately to signal the change to the peer OSP entity. This may be done by either sending an N-PDU with an 
empty payload or immediately forwarding the packetiser buffer. 

RTRL may also be set to or 1 by the OSP entity as a result of buffer conditions within the OSP entity. 

Remote - variable RTRR 

The value of RTRR is updated from the RTR bit of every N-PDU received. When RTRR changes to 0, an OS- 
FLO WCONTROL.indication(STOP) primitive shall be sent immediately to the OSP user. When RTRR changes to 1, an 
OS-FLOWCONTROL.indication (START) primitive may be sent immediately to the OSP user or this may be delayed 
subject to buffer conditions. 

STOP and START indications may also be sent at any time as a result of buffer conditions within the OSP entity. 
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B.7 Break handling 



When an OSP entity receives an OS-BREAK.request from its user it shall immediately send an N-PDU (type User Data) 
with the Break Request (BR) bit in the OSP header set to 'signal break' and an empty payload. Any data in the packetiser 
buffer shall be discarded and not transmitted in the N-PDU. Further data received from the OSP user shall be processed 
in the normal way. The OSP entity shall discard any buffered data already received from its peer entity and, when 
operating over a reliable service, shall continue discarding received N-PDUs (type user data) until it receives one with 
the Break Acknowledge (BA) bit in the OSP header set to 'acknowledge break '. Any data in the received N-PDU shall 
be processed in the normal way. N-PDUs (type control) are not discarded. 

When operating over an unreliable service, the OSP entity sending 'signal break' shall protect itself from the risk of 
lockup resulting from the loss of either or both of the N-PDUs containing 'signal break' or 'break acknowledge'. This is 
implementation-dependent. (A simple implementation could resume processing received N-PDUs immediately and 
ignore any received 'break acknowledge'.) When an OSP entity receives an N-PDU (type User Data) with the BR bit set 
to 'signal break' it shall immediately signal a break to its user with an OS-BREAK.indication. The OSP entity shall 
discard all buffered data for both directions of flow and acknowledge the break by sending an N-PDU (type User Data) 
with the Break Acknowledge (BA) bit in the OSP header set to 'acknowledge break'. This may either be sent 
immediately with no data or wait until one of the forwarding criteria is satisfied. 



B.8 Control block transport 



An OSP user may use the OS-CONTROL.request primitive to send a C-PDU (block of control information) consisting 
of zero or more octets to its peer user. An N-PDU (type Control Block) is sent immediately, regardless of whether there 
is any data in the packetiser buffer or flow control condition. If it is necessary to forward the buffer contents before 
sending the control block, the OSP user should issue an OS-FORWARD. request before the OS-CONTROL.request. The 
C-PDU is delivered immediately to the receiving OSP user with the OS-CONTROL.indication primitive, regardless of 
the state of the depacketiser buffer or local flow control condition. The octet ordering within the block and the block 
boundaries are preserved. 



B.9 Quality of Service 



The Quality of Service (QoS) provided by the OSP layer is determined almost entirely by that provided by the 
underlying protocol layers. However, the Packet Assembly and Disassembly functions introduce an additional variable 
delay into the transmission path. This delay can be limited at the risk of making less efficient use of network resources 
(particularly radio resources). The PAD function is described in detail in its own section. 

The QoS provided by the underlying protocol layers is defined by the QoS profile assigned to the OSP context. 

Precedence class - as required 

Delay class - as required but should be consistent with the PAD forwarding strategy 

Reliability class - class 1 for reliable service, class 3 for unreliable service 

Peak throughput class - as required 

Mean throughput class - as required 



B.10 OSP version 



In order to allow the possible coexistence in the future of multiple versions of OSP, each version shall be assigned a 
version number. The use of a particular version may be negotiated by the peer OSP entities using the OSP version 
subparameter of the protocol configuration options parameter in the PDP context activation request, accept and reject 
messages. The default in the event of no negotiation taking place is this initial version (0). 
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B.1 1 Protocol Configuration Options 

The following generic OSP configuration options parameters are defined for use in the various PDP Context Activation 
control messages. They use the syntax described in GSM 04.08. Option IDs 0-127 are reserved for generic use. 
Additional parameters with IDs in the range 128-255 may be defined for specific uses of the OSP. 

Parameter values may be negotiated between the MT and GGSN OSP entities. This is a two phase negotiation with the 
MT making a set of proposals and the GGSN either accepting each value or proposing an alternative. The MT must 
either accept the new set or the connection attempt fails. The alternative values are proposed in either a PDP context 
activation accept or reject message. 

The accept message should be used if there is a reasonable likelihood that the alternative will be acceptable to the MT, 
e.g. a downgrading of buffer size, since the connection may then immediately continue. If the alternative is unacceptable 
the MT immediately deactivates the context. 

The reject message should be used if it is likely that the alternative will not be acceptable, or if a significant charge 
would be incurred if the context were to be activated by the GGSN and then immediately deactivated by the MT. If the 
alternative is acceptable the MT may reattempt context activation using the values suplied by the GGSN. 

B.1 1.1 OSP version 

This parameter is optional. It allows the MT and GGSN to negotiate a mutually acceptable version of OSP. If omitted, 
the initial (version 0) of OSP is assumed. 

Option ID 

Length 1 

Contents indicates this (initial) version of OSP. Other values are reserved for future versions. 



B.1 1 .2 GGSN PAD parameters 



This options parameter is optional and may be used if the OSP entity in the GGSN contains a PAD function. It allows 
the MT and GGSN to negotiate a mutually acceptable set of PAD parameters for the GGSN PAD. The maximum buffer 
size parameters may be negotiated even when the OSP entity in the GGSN does not contain a PAD. If not relevant to the 
GGSN OSP entity, the PAD options parameter shall be ignored. 

Option ID 1 

Length3n (n = number of PAD parameters) 

Contents Pairs of (PAD parameter, value) 

The PAD parameter is 1 octet in length. The value is 2 octets in length. 

Valid PAD parameters are listed in the section describing the Packet Assembly/Disassembly function. 
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